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Description 
Intrusion Detection 

Background of Invention 
Field of Invention 

[0001] The present invention relates generally to the field of 
computer and network security. More specifically, the 
present invention is related to intrusion detection and iso- 
lation. 
Discussion of Prior Art 

[0002] p r jor art solutions proposed to prevent intrusion in a host 
system fall under two main categories: external protection 
or internal protection. External protection scenarios in- 
clude (but are not limited to) firewalls and routers which 
provide protection against various attacks (e.g., denial of 
service or DoS attacks) on a network infrastructure. The 
firewall approach prevents unauthorized access from an 
outsider (such as, an unauthorized user or hacker) by 
monitoring traffic on critical incoming ports. The firewall 
security layer is a control layer inserted between a local 



private network and an outside internet network. The fire- 
wall security layer permits only some traffic to pass 
through. The firewall is configured by a host master of the 
local private network based on the local private network's 
security policy. For example, the firewall can be config- 
ured to block: (a) traffic of a certain type, (b) traffic from 
certain addresses, or (c) traffic from all but a predeter- 
mined set of IP addresses. Firewalls also provide several 
schemes such as port forwarding and DMZ type applica- 
tions. Additionally, they can, but often do not, limit out- 
going port connections. The firewall, moreover, cannot 
block all IP addresses. An attacker (outsider, unauthorized 
user or hacker) is able to exploit this vulnerability. In this 
scenario, the attacker masks any harmful intent at the be- 
ginning of a session, gains access to sensitive data, and at 
a later point, attacks the host system. The firewall security 
layer has to update the harmful addresses after such at- 
tack or intrusion occurred. Thus, the firewall solution fails 
to offer a real-time blocking solution with regard to such 
harmful IP addresses. 
[0003] internal protection schemes have been designed to pre- 
vent breaches in security through the use of file permis- 
sion, directory access, and execution permission usually 



set as part of the file system associated with the host. 
This prevents unauthorized users from accessing sensitive 
aspects of the system. 

[0004] The question of how to determine, programmatically, that 
a system has been breached is a interesting problem. 
There have been several efforts in the industry that only 
partial solutions to address this issue. 

[0005] whatever the precise merits, features, and advantages of 
the above mentioned prior art internal or external protec- 
tion schemes, none of them achieves or fulfills the pur- 
poses of the present invention. 
Summary of Invention 

[0006] jhe present invention provides for a method to detect in- 
trusion in a host via a monitoring daemon operating in 
conjunction with a configuration file defining data entities 
(e.g., system files, configuration files, directories, etc) to 
be monitored. The method as implemented in the host 
comprises the steps of: (a) monitoring data entities via 
comparing a locally stored copy of a digital signature 
(e.g., an MD5 signature) associated with each data entity 
against a corresponding digital signature stored in a first 
remote database (e.g., an MD5 database); and (b) upon 
identifying a mismatch in compared digital signatures, is- 



suing an instruction to record an entry in a log file located 
in a second remote database (e.g., a SYSLOG database), 
said entry identifying a possible intrusion in said host. In 
one embodiment, the host communicates with the first 
(e.g., an MD5 database) and second (e.g., a SYSLOG 
database) remote databases via one or more network in- 
terfaces and, subsequent to the above-mentioned step 
(b), the method further comprises the step of issuing a 
command to bring down the network interfaces to isolate 
the host. In another embodiment, the method comprises 
the additional step of issuing a command to the operating 
system of the host to bring it to a single user state. 

[0007] | n an extended embodiment, the first remote database 
(e.g., an MD5 database) and the second remote database 
(e.g., a SYSLOG database) are located on a single server 
or, alternatively, on a plurality of servers belonging to a 
common local area network. 

[0008] | n another embodiment, communications between the 
host and first remote database (e.g., an MD5 database) 
and communications between the host and second remote 
database (e.g., an SYSLOG database) are encrypted (for 
example, via the secure shell protocol). 

[0009] The present invention also provides for a system to detect 



intrusion comprising: (a) a host running a monitoring 
daemon working in conjunction with a configuration file 
(the configuration file identifies files and directories to be 
monitored in the host), wherein the host communicates 
with external networks via one or more network interfaces 
and the monitoring daemon dynamically monitors the files 
and directories identified by the configuration file by 
comparing a locally stored digital signature corresponding 
to each file or directory against a remotely stored corre- 
sponding digital signature; (b) a digital signature database 
located remotely from the host and storing the digital sig- 
natures associated with files and directories identified by 
the configuration file; and (c) a log database located re- 
motely from the host and recording entries corresponding 
to mismatches between a digital signature stored in said 
host and a corresponding digital signature in the digital 

signature database. 
Brief Description of Drawings 

[0010] Figure 1 illustrates an exemplary embodiment associated 
with the system of the present invention. 

[001 1] Figure 2 illustrates a flow chart outlining one embodiment 
of the present invention'^ method for detecting an intru- 
sion in a host system. 



Detailed Description 

[0012] while this invention is illustrated and described in a pre- 
ferred embodiment, the invention may be produced in 
many different configurations. There is depicted in the 
drawings, and will herein be described in detail, a pre- 
ferred embodiment of the invention, with the understand- 
ing that the present disclosure is to be considered as an 
exemplification of the principles of the invention and the 
associated functional specifications for its construction 
and is not intended to limit the invention to the embodi- 
ment illustrated. Those skilled in the art will envision 
many other possible variations within the scope of the 
present invention. 

[0013] Figure 1 illustrates an exemplary embodiment associated 
with the system of the present invention. System daemon 
(designated as "jtrip"in figure 1) 101 is a daemon that is 
started through normal system startup procedures. It 
should be noted that the common UNIX system is used as 
an example to illustrate the functionality of the present 
invention, but other systems can also be used in conjunc- 
tion with the present invention. Hence, the type of operat- 
ing system should not be used to limit the scope of the 
present invention. At start up, system daemon 101 reads 



(in real-time continuous manner) a configuration file 
(illustrated as "Jtrip.conf'in figure 1) 104 and determines 
which directories, normal system files, and configuration 
files of file system 102 are to be monitored in a real-time 
continuous manner. An example of a configuration file is 
provided below (it should be noted that lines marked with 
a "#"symbol in the configuration file correspond to com- 
ments and, hence, the system daemon 101 ignores such 
statements). 

[0014] 



#_ 

# Jtrip Configuration File for intrusion detection daemon 
#_ 

# Directives for script are as follows 

# DIR=/bin This tells jtrip to use all members of /bin 

# to include in the database 

# FILE=/bin/rm This tells jtrip to use only this file 

# when creating the database 

# CONF=/etc/host this tells jtrip that this is a config 
ttfile and may be checked on a different 

# Schedule from other directives this is 

# used to check vendor supplied control 

# files 



DIR=/bin 
DIR^/sbin 
DIR=/usr/sbin 
DIR =/usr/local/sbin 
FILE^f etc/hosts, equiv 
CONF=/etc/pam. conf 



[0015] The Jtrip. conf configuration file 104 tells Jtrip system dae- 
mon 101 which data entities (e.g., directories, files, etc.) of 
file system 102 are to be monitored in a real-time contin- 
uous manner. The data includes a valid digital signature 
such as a MD5 signature, correct permissions, ownership 
of the file, and information indicating if the file still exists. 
An MD5 signature is a cryptographic hash code in a MD5 



database 103. The MD5 signature (a cryptographic hash 
code) is generated for each receiving file and compared to 
a previous signature for that file stored in the MD5 
database 103. The system daemon 101 identifies any mis- 
match between a locally stored digital signature against 
the remotely stored (at the MD5 database 103) digital sig- 
nature. Thejtrip 101 reads valid known MD5 signatures 
and permissions associated with data entities from the re- 
mote MD5 database 103. If any modification are detected 
based upon the comparison of the digital signatures, the 
Jtrip system daemon 101 alarms a root user that an intru- 
sion has taken place. Hence, thejtrip system daemon 101 
can be used to monitor one or more files and/or one or 
more directories. It should be emphasized that the MD5 
database 103 is located at a remote location, whereby it is 
isolated physically as well as programmatically from the 
monitored host system. A SYSLOCD database 106 is also 
provided at a remote location. It should be emphasized 
that, just as the MD5 database, the SYS LOG D database 106 
is also located at a remote location, whereby it is isolated 
physically as well as programmatically from the monitored 
host system. 

[0016] | n one embodiment, the SYSLOGD database 106 is remote 



from both the MD5 database 103 and the host system. In 
an alternate embodiment, the SYSLOGD database and the 
MD5 database are located on a single server or a plurality 
of servers belonging to a common network (e.g., local 
area network). 

[0017] Once an intrusion (from outsider, un-authorized user, or 
hacker) is detected (in real-time continuous manner), any 
of, or a combination of, the following steps are taken to 
protect the rest of the host system from the compromised 
system: 1. a log is written to the remote SYSLOGD database 
106 indicating the occurrence of a possible intrusion;2.an 
IFCONFIG down command is issued (from Jtrip 101) to one 
or more network interface 105 wherein the IFCONFIG down 
commands isolate the host system from the outside net- 
work; and3.an INIT 1 command is issued (by the Jtrip 101) 
to the operating system for taking the host system down 
to single user state, whereby the INIT 1 command limits 
the access to a single user and the access is physical to 
the interface 105. 

[0018] Figure 2 illustrates a flow chart outlining one embodiment 
of the present invention'^ method for detecting an intru- 
sion in a host system, wherein the host communicates 
with external networks via has one or more network inter- 



faces. The method comprising the steps of: (a) reading a 
configuration file to identify data entities to be monitored 
on a host step 202; (b) for each data entity to be moni- 
tored, extracting a digital signature from said host step 
204; (c) for each data entity to be monitored, querying a 
remote digital signature database via a network interface 
and requesting a digital signature corresponding to the 
digital signature extracted from the host step 206; (d) for 
each data entity to be monitored, receiving the corre- 
sponding digital signature from the remote digital signa- 
ture database step 208; (e) matching digital signature re- 
ceived from said remote digital signature database with 
digital signature extracted at said host step 210; (f) upon 
identifying a mismatch, transmitting an instruction to a 
remote log database via the network interface, wherein 
the instruction is executed in the remote log database to 
record an entry in a log file indicating a possible intrusion 
in the host step 212; and (g) performing any one of, or a 
combination of, the following steps:(i) issuing a command 
to bring down the network interfaces to isolate the host 
step 214; or(ii) issuing a command to an operating system 
of host to bring the host to a single user state step 216. 
[0019] | n another embodiment, communications between the 



host and SYSLOGD database and communications between 
the host and the MD5 database are encrypted (for exam- 
ple, via the secure shell protocol). 
[0020] Furthermore, the present invention includes a computer 
program code based product, which is a storage medium 
having program code stored therein which can be used to 
instruct a computer to perform any of the methods asso- 
ciated with the present invention. The computer storage 
medium includes any of, but not limited to, the following: 
CD-ROM, DVD, magnetic tape, optical disc, hard drive, 
floppy disk, ferroelectric memory, flash memory, ferro- 
magnetic memory, optical storage, charge coupled de- 
vices, magnetic or optical cards, smart cards, EEPROM, 
EPROM, RAM, ROM, DRAM, SRAM, SDRAM, and/or any 
other appropriate static or dynamic memory or data stor- 
age devices. 

[0021] implemented in computer program code based products 
are software modules for: (a) monitoring data entities via 
comparing a locally stored copy of a digital signature 
(e.g., an MD5 signature) associated with each data entity 
against a corresponding digital signature stored in a first 
remote database (e.g., an MD5 database); (b) upon identi- 
fying a mismatch in compared digital signatures, issuing 



an instruction to record an entry in a log file located in a 
second remote database (e.g., a SYSLOG database), said 
entry identifying a possible intrusion in said host; (c) issu- 
ing a command to bring down one or more network inter- 
faces to isolate the host; and (d) issuing a command to 
the operating system of the host to bring it to a single 

user state. 
Conclusion 

[0022] a system and method has been shown in the above em- 
bodiments for the effective implementation of a system 
and method implementing host intrusion detection and 
isolation. While various preferred embodiments have been 
shown and described, it will be understood that there is 
no intent to limit the invention by such disclosure, but 
rather, it is intended to cover all modifications and alter- 
nate constructions falling within the spirit and scope of 
the invention, as defined in the appended claims. For ex- 
ample, the present invention should not be limited by 
host operating system, particular database, type of en- 
cryption link between the host and the MD5 database, 
type of encryption link between the host and the SYSLOGD 
server, or specific hardware interface. 

[0023] The above enhancements are implemented in various 



computing environments. For example, the present inven- 
tion may be implemented on a conventional IBM PC or 
equivalent, multi-nodal system (e.g., LAN, WAN) or net- 
working system (e.g., Internet, WWW, wireless web). All 
programming related thereto are stored in computer 
memory, static or dynamic, and may be retrieved by the 
user in any of: conventional computer storage, display 
(i.e., CRT) and/or hardcopy (i.e., printed) formats. The 
programming of the present invention may be imple- 
mented by one of skill in the art of network programming. 



